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Abstract 

From the beginning the Geant4 Visualisation System was designed 
to support several simultaneous graphics systems written to common ab- 
stract interfaces. Today it has matured into a powerful diagnostic and 
presentational tool. It comes with a library of models that may be added 
to the current scene and which include the representation of the Geant4 
geometry hierarchy, simulated trajectories and user-written hits and digi- 
tisations. The workhorse is the OpenGL suite of drivers for X, Xm, Qt and 
Win32. There is an Open Inventor driver. Scenes can be exported in spe- 
cial graphics formats for offline viewing in the DAWN, VRML, HepRApp 
and gMocren browsers. PostScript can be generated through OpenGL, 
Open Inventor, DAWN and HepRApp. Geant4's own tracking algo- 
rithms are used by the Ray Tracer. Not all drivers support all features 
but all drivers bring added functionality of some sort. This paper de- 
scribes the interfaces and details the individual drivers. 
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1 Introduction 



Geant4 arose out of a desire to take advantage of a new programming paradigm, 
namely object-oriented programming, to create a toolkit for the simulation of 
the passage of particles and radiation though matter that could be developed 
and maintained by physicists expert in radiation and particle interactions from 
around the world. The initiative for a new toolkit came from KEK and CERN 
in the early 1990s and this led to a research and development project, RD44, 
funded by CERN from 1994-1998 in the run up to the commissioning of the 
LHC, in which the paradigm was realised in the C-l — h programming language. 
Many other institutes, notably SLAC, also provided support. Many physicists 
from around the world gave their time and effort as part of their research pro- 
grammes. Geant4 was born out of this project in 1999 as an independent 
collaboration with its own collaboration agreement, providing open code that 
has found applications in medicine, space and related domains as well as nu- 
clear and particle physics that were its origins. The modular design, which 
is a natural consequence of object-oriented programming, makes possible the 
development by many authors in parallel in a well defined and safe manner, a 
process that continues to the present day. A more detailed history of Geant4 
can be found in the original general paper. [1] Some more recent developments 
and applications are described in Reference [2]- 

The visualisation system was designed to facilitate the development of Geant4 
and its applications. It was written to a basic abstract interface and itself intro- 
duced interfaces for multiple drivers. This was first described in Reference [3] 
and implementation details are given in the Toolkit Developers Guide. ^ The 
current paper brings this up to date and describes progress since then. 

A good practical introduction to the Geant4 Visualisation System is given 
in Reference [5]. 

2 Overview of the Geant4 Visualisation System 

Every application that needs to use the Geant4 Visualisation System must in- 
stantiate a G4VisMaiiager and register visualisation drivers as desired from those 
available on the computing platform. (This is done automatically should the 
application be built through the Geant4 build system and G4VisExecutive as 
described below.) The application communicates with the visualisation manager 
through basic abstract interfaces, also described below. 

The Geant4 Visualisation Manager has the ability to build "scenes" (G4Scene 
objects) with any number of geometrical (detector) components, axes, annota- 
tions and (at the end of event or run) the potential to draw particle trajectories, 
hits (representations of effects, for example, energy deposit, of particles) and 
digitisations (ultimate signals from sensitive components — "digits" for short). 
It defines, through the G4VSceneHaxidler interface, "scene handlers" that trans- 
late the scene into messages for a particular graphics system and, through the 
G4VViewer interface, "viewers" that render to the final device (screen, file or 
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terminal). Any scene can be associated with any scene handler and viewed with 
any viewer. A scene handler-viewer(s) combination is referred to as a driver. 
One may instantiate any number of drivers of any type, each with any number 
of viewers, and switch between them. 

It is a natural consequence of object oriented design that any driver that 
conforms to these interfaces can be accessed by the visualisation manager and 
we take advantage of this to write multiple drivers with different characteristics 
and qualities — for example, OpenGL and Open Inventor for fast drawing (with 
varying degrees of interactivity according to the computing platform) , DAWN 
for high quality PostScript output, HepRepFile for scene browsing, VRML for 
virtual reality, Ray Tracer for photorealistic images, gMocren for medical images 
and ASCIITree for a text dump. 

The Geant4 Visualisation Manager keeps a list of scenes, scene handlers 
and viewers. There is always a current viewer serviced by its scene handler 
with its scene. Drawing requests made by the application or re-issued by the 
visualisation manager are always made to the current viewer. If a scene is 
changed, or on user request, all views of that scene are rebuilt. 

The Geant4 Visualisation System is implemented as a "plug-in". It may 
use any part of the toolkit but itself may only be used by a Geant4 user 
application or by the toolkit itself through the basic abstract interfaces in a 
protected way, as described below. 

The Geant4 Visualisation System is currently being used across a wide 
range of Geant4 applications in high energy physics, nuclear physics, space 
and medicine. 

3 The Basic Abstract Interfaces 

Following our object-oriented design, any Geant4 Visualisation Manager must 
implement the G4VVisManager interface. This is the working interface for all 
drawing messages. As one can see from Figure [T] it is generously endowed with 
possibilities. 

The Geant4 visualization manager interface is available to all Geant4 code 
whether in a Geant4 user application or in the toolkit itself. However, the coder 
must check that a concrete implementation actually exists and avoid using the 
interface if not; for example: 

G4VVisManager* pVVisManager = G4VVisManager : : GetConcretelnstance () ; 
if (pVVisManager) { 

pWisMaiiager->Draw(circle) ; 

This allows one to build a Geant4 application without a concrete imple- 
mentation, for example for batch production, even if such code remains in the 
application or the toolkit (which it certainly does). 

A second interface — G4VGraphicsSceiie (Figure[2]) — is private to the toolkit. 
It is not available for application developers. It is used by the toolkit — geometry 
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class G4VVisMaiiager { 

public ; 

static G4WisMaiiager* GetConcretelnstance (); 
virtual void Draw (const G4Circle&, 

const G4Transf orm3D& objectTransf ormation = G4Transf ormSDC) ) = 0; 
virtual void Draw (const G4NURBS&, 

const G4Transf orm3D& objectTransf ormation = G4Transf ormSD () ) = 0; 
virtual void Draw (const G4Polyhedron& , 

const G4Transf orm3D& objectTransf ormation = G4Transf ormSD () ) = 0; 
virtual void Draw (const G4Polyline&, 

const G4Transforiii3D& objectTransf ormation = G4Transform3D()) = 0; 
virtual void Draw (const G4Polymarker&, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw (const G4Scale&, 

const G4Transf orm3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw (const G4Square&, 

const G4Transf orm3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw (const G4Text&;, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw2D (const G4Circle&, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw2D (const G4Polyhedron&, 

const G4Transf orm3D& objectTransf ormation = G4Transform3D()) = 0; 
virtual void Draw2D (const G4Polyline&, 

const G4Transf orm3D& objectTransf ormation = G4Transf ormSD () ) = 0; 
virtual void Draw2D (const G4Polymarker& , 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw2D (const G4Square&, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw2D (const G4Text&, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 
virtual void Draw (const G4VHit&) = 0; 
virtual void Draw (const G4VDigi&) = 0; 
virtual void Draw (const G4VTrajectory&) = 0; 

virtual void Draw (const G4LogicalVolume&;, const G4VisAttributes& , 
const G4Transform3D& objectTransf ormation = G4Transform3D()) = 0; 

virtual void Draw (const G4VPliysicalVolume&, const G4VisAttributes&, 
const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 

virtual void Draw (const G4VSolid&, const G4VisAttributes&, 

const G4Transform3D& objectTransf ormation = G4Transf orm3D() ) = 0; 



Figure 1: The basic G4VVisMcLnager interface. 
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class G4VGraphicsScene -[ 
public : 

G4VGraphicsScene() ; 

virtual '"G4VGraphicsScene () ; 

virtual void PreAddSolid (const G4Transf orm3D& objectTransformation, 
const G4VisAttributes& visAttribs) = 0; 



virtual 


void 


PostAddSolid C) 


= 0; 






virtual 


void 


AddSolid 


(const 


G4B0X&) 







virtual 


void 


AddSolid 


(const 


G4Cons&) 







virtual 


void 


AddSolid 


(const 


G4Tubs&) 







virtual 


void 


AddSolid 


(const 


G4Trd&) 







virtual 


void 


AddSolid 


(const 


G4Trap&) 







virtual 


void 


AddSolid 


(const 


G4Spliere&) 







virtual 


void 


AddSolid 


(const 


G4Para&) 







virtual 


void 


AddSolid 


(const 


G4Torus&) 







virtual 


void 


AddSolid 


(const 


G4Polycone&) 







virtual 


void 


AddSolid 


(const 


G4Polyhedra&) 







virtual 


void 


AddSolid 


(const 


G4VSolid&) 








virtual void AddCompound (const G4VTrajectory&) 
virtual void AddCompound (const G4VHit&) = 

virtual void AddCompound (const G4VDigi&) = 

virtual void AddCompound (const G4THitsMap<G4double>fi) = 
virtual void BeginPrimitives 

(const G4Transf orm3D& objectTransformation = G4Transf ormSD C) ) 
virtual void EndPrimitives () = 0; 
virtual void BeginPrimitives2D 

(const G4Transf orm3D& objectTransformation = G4Transf ormSDC) ) 
virtual void EndPrimitives2D () = 0; 
virtual void AddPrimitive (const G4Polyline&) = 
virtual void AddPrimitive (const G4Scale&) = 

virtual void AddPrimitive (const G4Text&) = 

virtual void AddPrimitive (const G4Circle&) = 

virtual void AddPrimitive (const G4Square&) = 

virtual void AddPrimitive (const G4Polymarker&) = 
virtual void AddPrimitive (const G4Polyhedron&) = 



// For solids not above. 
= 0: 



0; 



Figure 2: The G4VGraphicsScene low-level interface. 



and modeling in particular. The visualisation manager is expected to initiate 
its use by providing a reference to a concrete implementation. 

In summary, a visualisation system is required to implement two interfaces — 
G4VVisManager (Figure [T]) and G4VGraphicsScene (Figure [2|. The latter is, in 
fact, intended to represent the "scene handler". Objects that are passed to it 
(G4Box objects, etc.) are required to be turned into visible renderings. Quite 
how this is done is up to the visualisation system. 

4 The Geant4 Visualisation System 

So now we are in a a position to describe the Geant4 Visualisation System, 
which is the implementation of the above interfaces that is distributed with the 
Geant4 toolkit. 

Geant4 defers to the application developer the decision of which external 
graphics packages should be required. Accordingly, it is the application devel- 
oper's responsibility to declare which graphics drivers should be made avail- 
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|G4WisManager | 


|G4VGraphicsSystem | 










lG4VisManager 1 


|G4VSceneHandler 1 




|G4VisExecutive | 


|G40penGLSceneHandler | 



Pure abstract class 



G4VViewer Base class 



Figure 3: The basic class diagram. OpenGL is shown as an example; in fact the 
system is capable of handling multiple scene handlers and viewers. 

able to the end user. He or she makes these declarations by instantiating a 
G4VisM£aiager (written to the G4VVisManager interface) and registering appro- 
priate graphics drivers. The Geant4 distribution provides a general purpose 
sub-class called G4VisExecutive, which collaborates with the Geant4 build 
system to offer all available drivers and which is used in all Geant4 examples. 
This is shown in Figure [Sj 

G4VSceneHaiidler is written to the G4VGraphicsSystem interface and itself 
is the base class for graphics-library dependent concrete scene handlers, for 
example, for OpenGL. The system is capable of handling multiple drivers, i.e., 
multiple scene handlers and viewers. 

4.1 Visualisation of touchables 

Geant4 has a layered geometry structure, in which solids define shapes, log- 
ical volumes add material information to solids and physical volumes place a 
given logical volume in space. To make efficient use of memory, Geant4 provides 
mechanisms whereby a single physical volume may have more than one place- 
ment, using mechanisms called Replica placement or Parameterised placement. 
Whether a physical volume has only one placement, or many placements, each 
placement is called a touchable. 

The visualisation system must deal in touchables, and it is the job of G4PhysicalVolumeModel 
to roll out the Geant4 geometry into touchables. To avoid being overwhelmed, 
it is possible to specify starting points in the geometry hierarchy, such as specific 
sub-detectors, and limit the depth of descent so as to avoid too much detail. 
One can also control, for example, the visibility with G4VisAttributes (Section 



4.51; invisible touchables may then be suppressed (culled). 

It is possible to edit the G4VisAttributes of logical volumes with /vis/geometry/ 
commands and to modify the G4VisAttributes of individual touchables with 
/vis/touchable/ commands. The latter can also be done interactively in the 
OpenGL Qt viewer. 
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4.2 Visualisation of transients 



"Transients" is a term for entities that appear for a limited time on a "perma- 
nent" background, for example, particle trajectories in a detector. The Geant4 
Visualisation System distinguishes these; smart drivers may take advantage. For 
example the OpenGL "stored" system (Section 6.1.1) keeps separate lists in its 
graphical database for transient and permanent objects, and the Geant4 Visu- 
alisation Manager clears and rebuilds the former without having to rebuild the 
latter. This makes is very efficient for displaying event after event on a fixed 
detector image. 

The Geant4 Visualisation System allows one to display particle trajectories, 
hits and digits event by event or to accumulate them, one on the other, until 
the end of run. 

This is fine for drivers with their own graphical database, but in such cir- 
cumstances, not-so-smart drivers have to re-draw both permanent and transient 
objects, with a noticeable performance degradation. Moreover they may not 
even have the ability to remember permanent objects, let alone transients. For 
these drivers the Geant4 Visualisation System keeps a memory of permanent 
objects (for example, it may always re- visit the geometry hierarchy to rebuild a 
detector image) and also keeps a memory, to a limited but considerable extent, 
of transient objects such as particle trajectories, hits and digits that are stored 
in simulated events. With this feature, described in Section |4.3| all drivers, 
including the not-so-smart, can recover the transients and emulate the super- 
position of transients on permanents, a switch of viewpoint or even a switch of 
drivers. 

Transients that are generated from user code will not be recoverable in this 
way, unless the user encloses the code in a User Vis Action-see Section [4!6| 



4.3 Event storing 

The Geant4 Visualisation Manager asks the Run Manager to keep events so 
that they may be accessed to redraw, say, the particle trajectories, hits and 
digits in a view. This is particularly useful for drivers that do not have their own 
graphical database or when switching from one driver to another. The default 
behaviour is to keep the last 100 events, but the number may be adjusted to 
take into account available memory; also user code can provide algorithms to 
specify which events should be kept. 



4.4 Trajectory modelling and filtering 

An extensive set of models and filters for trajectories drawing is available. They 
control the colour and visibility by particle type and the visibility by momentum 
or detector volume, for example. Some commands are part of the start-up script 
shown in Figure [8j Models may also select whether the trajectory is drawn as 
a line, as step points, or as both. 
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/G4TrajectoriesHodel: 

Event ID (Event ID) : G4iiit 
G4RichTrajectory : 

Creator Process Name (CPN) : G4String 

Creator Process Type Name CCPTN) : G4String 

Charge (Ch) : unit: e+ (G4double) 

Ending Process Name (EPN) : G4String 

Ending Process Type Name (EPTN) : G4String 

Final kinetic energy (FKE) : G4BestUnit CG4double) 

Final Next Volume Path (FKVPath) : G4String 

Final Volume Path (FVPath) : G4String 

Track ID (ID) : G4int 

Initial kinetic energy (IKE): G4BestUnit (G4double) 
Initial momentum magnitude (IHag) : G4BestUnit (G4double) 
Initial momentum (IHom) : G4BestUnit (G4ThreeVector) 
Initial Next Volume Path (INVPath) : G4String 
Initial Volume Path (IVPath) : G4String 
No. of points (NTP) : G4int 
PDG Encoding (PDG) : G4int 
Parent ID (PID) : G4int 
Particle Name (PN) : G4String 
G4RichTrajectoryPoint : 

Auxiliary Point Position (Aux) : G4BestUnit (G4ThreeVector) 
Process Defined Step (PDS) : G4String 
Process Type Defined Step (PTDS) : G4String 
Position (Pos) : G4BestUnit (G4ThreeVector ) 
Post-step-point status (PostStatus) : G4String 
Post-step-point global time (PostT) : G4BestUnit (G4double) 
Post-step Volume Path (PostVPath) : G4String 
Post-step-point yeight (PostW) : G4double 
Pre-step-point status (PreStatus) ; G4String 
Pre-step-point global time (PreT) : G4BestUnit (G4double) 
Pre-step Volume Path (PreVPath) : G4String 
Pre-step-point weight (PreW) : G4double 
Remaining Energy (RE): G4BestUnit (G4double) 
Total Energy Deposit (TED) : G4BestUnit CG4double) 



Figure 4: The attributes of a G4RichTrajectory object. 



A similar but less extensive set is available also for user-defined hits and 
digits. A user may add attributes to trajectories, hits and digits and filter them 
at drawing time with /vis/filtering/ commands. 

4.5 Attributes 

Every drawable entity is assigned visualisation attributes G4VisAttributes ei- 
ther by the user or from a modifiable default set. They include visibility (i.e., 
drawn or not if culling is active), colour, line width, line style, and the ability to 
"force" some modes of drawing, such as wireframe or with surfaces, regardless 
of the general user request. 

Some entities have additional attributes in the form of G4AttDef and G4AttValue 
pairs, which are strings to be interpreted as text, integers, doubles or three- 
vectors, with or without dimension (units), following the HepRep attribute 
design. [S] For example, trajectories acquire particle type, momentum, volume 
name, process type. A full list for G4RichTrajectory objects is shown in Figure 
[4[ (Note that this is memory- consuming; by default trajectories as stored as 
G4Trajectory objects with fewer attributes.) 

Touchables also get attributes — see Figure [5) 

It is these attributes that are selectable with /vis/filtering/ commands, 
as mentioned above, and that may be dumped by picking with pick- sensitive 
drivers — OpenGL, Openlnventor and HepRApp (the browser for HepRepFile) — 
see below. 
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G4PhysicalVolumeModel : 

Material Density (Density); G4BestUnit CG4double) 
Dump of Solid properties (DrapSol) ; G4String 
Entity Type (EType) ; G4String 
Logical Volume (LVol) : G4String 
Material Name (Material) ; G4String 
Physical Volume Path (PVPath) ; G4String 

Material Radiation Length (Radlen) ; G4BestUnit (G4double) 
Cuts Region (Region) ; G4String 

Root Region (0/1 = false/true) (RootRegion) ; G4bool 
Solid Name (Solid) ; G4String 

Material State (enum undefined, solid, liquid, gas) (State): G4String 
Transformation of volume (Trans) ; G4String 



Figure 5: The attributes of touchables provided by G4PhysicalVolumeModel. 



class StandaloneVisAction: public G4VUserVisAction { 
virtual void DrawC); 

}; 

void StandaloneVisAction: :Draw() { 

G4VVisManager* pVisManager = G4VVisManager : : GetConcretelnstance C) ; 
if CpVisManager) -[ 
// Simple box . . . 

pVisManager->Draw(G4Box{"box" ,2*m,2*m,2*m) , 

G4VisAttributes (G4Colour (1,1,0))); 
// Boolean solid. . . 
G4Box boxAC'boxA" ,3*m,3*m,3*m) ; 
G4Box boxBC'boxB" , l*m, l*m, l*m) ; 

G4Subtract ionSol id subtracted C " subtract ed_boxes " , &boxA , &boxB , 
G4Translate3D(3*m,3*m,3*m)) ; 

pVisManager->DrawC subtracted, 

G4VisAttributes (G4Colour (0,1,1)), 
G4Translate3D(-6*m,-6*m,-6*m)) ; 

} 

} 



Figure 6: A User Vis Action that gives drawn objects a permanence. 



4.6 User Vis Actions 

As we have said, a user may draw to the current viewer at any time with C++ 
code written to the basic abstract interface (Section [3|. However, the drawing 



will belong to the set of unrecoverable "transients" (see Section 4.2 ) and will not 
be preserved on change of view or change of driver. A better strategy is to write 
a User Vis Action, a class that inherits G4UserVisAction, instantiate it and 
register it with the Geant4 Visualisation Manager. This way the visualisation 
manager can invoke the code repeatedly as required to give the drawn objects 
as sort of permanence. 

A few examples are included in the Geant4 distribution. exarniples/extended/visualization/userVisAd 
shows how to implement a user-defined logo, examples/extended/visualization/ stcmdalone 
shows, as the name implies, how the Geant4 libraries can be used as a "stan- 
dalone" multi-driver graphics library. Figure [6] shows the code that results in 
Figure [Tj The reader will notice that one may use the Geant4 geometry, in- 
cluding, for example, the Boolean solids (G4SubtractionSolid, etc.). 
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Figure 7: A result of the code shown in Figure [6j (This figure was produced 
with /vis/ogl/printEPS from an OpenGL stored Xm window.) 
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5 The User Interface 



A user may code to the basic abstract interface, G4VVisMcaiager, or, more usu- 



ally, use an extensive set of visualisation commands (Section 5.11 through the 
Geant4 User Interface. Geant4 offers several user interfaces, ranging from 
dumb terminal to graphical. In general, any user interface will work with any 
visualisation driver, except in the case of Qt 7 (which offers the most advanced 
interactivity, and for which the graphics window is closely coupled to the user 
interface) . 

A user may also read commands from a file by typing "/control/execute 
<f ilen£mie>" or by programming the reading of a file using G4UIm£m.ager : : ApplyCommand ( ) . 
This is typically to be found in the examples distributed with the Geant4 
toolkit. 



5.1 Visualisation commands 

The visualisation commands are too numerous to detail here. A full description 
of all commands is available in the Application Developers Guide. [8] 

For example, a user would instantiate a user interface and then issue com- 
mands, such as "/vis/open DGL" and "/vis/drawVolume" to get an image of 
the detector. Figure [8] shows a typical start-up script. After reading this file, 
"/run/beamOn 10", for example, would run the simulation and draw particle 
trajectories from 10 events. 



6 The Drivers 



Over the years we have developed, at the latest count, 14 drivers of various 
sorts (or upwards of 20 if one counts all the OpenGL variants and DAWN and 
VRML variants). A user may draw to the basic abstract interfaces, either in 



C-| — h code or, more usually, via visualisation commands (Section 5.1 ) through a 
user interface, and expect it to be rendered in one of a number of different ways: 



to a computer screen (graphics drivers. Section 6.1 ); or to a file for subsequent 
browsing (file-writing drivers, Section 6.2 There is also a category of pseudo- 
drivers (Section [6^ . 

Some drivers support picking, i.e., clicking on an item in the graphics window 
pops up a window of information or dumps a print-out of attributes to standard 
output. In this category are: HepRepFile; OpenGL Xll; OpenGL Qt; Open 
Inventor. 



6.1 Graphics drivers 

The workhorse of the Geant4 Visualisation System is the set of OpenGL 
drivers. We also have a graphics driver for Open Inventor and a driver, Ray- 
Tracer, that uses Geant4's own tracking algorithms to produce a ray-traced 
image. 
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/vis/open QGL 600x600-0+0 

# Disable auto refresh and quieten vis messages vhilst scene and 

# trajectories are established: 
/vis/viewer/set/autoRefresh false 
/vis/verbose errors 

/vis/drawVolume 

# Specify view angle; 

/vis/viewer/set/viewpointVectOr -10 
/vis/viewer/set/lightsVector -10 

# Specify style (surface, Hireirame, auxiliary edges,...) 
/vis/viewer/set/style wireframe 
/vis/viewer/set/auxiliaryEdge true 

/vis/ viewer/set/lineSegment sPerCircle 100 

# Draw smooth trajectories at end of event, showing trajectory points 

# as markers 2 pixels wide: 
/vis/scene/add/trajectories smooth 
/vis/modeling/trajectories/create/drawByCharge 

/vis/modeling/trajectories/drawByCharge-O/def ault/setDrawStepPtS true 
/vis/modeling/trajectories/drawByCharge-O/default/setStepPtsSize 2 

# To draw only gammas: 

#/vis/f iltering/trajectories/create/particleFilter 
#/vis/f iltering/trajectories/particleFilter-O/add gamma 

# To superimpose all of the events from a given run: 
/vis/scene/endOf Event Act ion accumulate 

# Decorations 

# Name 

/vis/set/textColour green 

/vis/scene/add/text2D -.9 24 ! ! exampleBl 

/vis/set/textLayout # Revert to normal (left adjusted) layout 
/vis/set/textColour # Revert to default text colour (blue) 

# Axes, scale, etc. 

/vis/scene/add/scale # Simple scale line 

/vis/scene/add/axes # Simple axes: x=red, y=green, z=blue. 

/vis/scene/add/eventID # Drawn at end of event 

/vis/scene/add/date # Date stamp 

/vis/scene/add/logo2D # Simple logo 

/vis/scene/add/logo # 3D logo 

# Frame 

/vis/set/colour red 
/vis/set/lineWidth 2 

/vis/scene/add/frame # Simple frame around the view 
/vis/set/colour # Revert to default colour (white) 

/vis/set/lineWidth # Revert to default line width (1.) 

# Attach text to one edge of Shs^el, with a small, fixed offset 
/vis/scene/add/text 6 -4 cm 18 4 4 Shapel 

# Attach text to one comer of Shape2, with a small, fixed offset 
/vis/scene/add/text 6 7 10 Cm 18 4 4 Shape2 

# To get nice view 

/vis/geometry/set/visibility World false 
/vis/geometry/set/visibility Envelope false 
/vis/viewer/set/style surface 
/vis/viewer/set/hiddenHarker true 
/vis/viewer/set/viewpointThetaPhi 120 150 

# Re-establish auto refreshing and verbosity: 
/vis/viewer/set/autoRefresh true 
/vis/verbose warnings 

# For file-based drivers, use this to create an empty detector view: 
#/vis/viewer/flush 



Figure 8: A tj^ical start-up script 
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6.1.1 OpenGL 



A particular feature of OpenGL is that one may store GL commands in a "dis- 
play list" that may be efficiently rendered by a graphics processing unit. We 
recommend this "stored mode" as the default option to get good performance 
for rotating, zooming, etc., without having to re- visit the Geant4 kernel. How- 
ever a complex detector or complex event structure can overwhelm a computer 
system, so we offer an "immediate mode" whereby objects are rendered directly 
to the screen, but to change viewpoint, for example, the graphics system re- 
visits the Geant4 kernel for information about the scene and makes all the 
coordinate calculations afresh, which is much slower. 

The OpenGL drivers have various degrees of interactivity depending on the 
availability of advanced graphics libraries. The simplest — OpenGL Xll (Unix) 
and Win32 (Microsoft Windows) — are passive. For example, to change the 
viewpoint one must issue a command, e.g., "/vis/viewer/ set/viewpoint ThetaPhi 
30 30 deg" . With Motif [9] libraries one can build OpenGL Xm; the viewer pro- 
vides some interactivity via pull-down menus, including rotation and zoom. The 
most sophisticated is the OpenGL Qt[7] driver, which offers a huge amount of 
interactivity, including rotation, pan and zoom, picking, drawing style, projec- 
tion style, etc. The Qt user interface, G4UIQt, which must be used with it, 
includes an interactive help system and an interactive portrayal of the scene, 
including the geometry hierarchy, through which one can change the colour and 
visibility of individual screen objects. Figure [9] shows a typical screen shot. 

The OpenGL driver also implements transparency and cutaways. 

A user may save the view to file in EPS format with /vis/ogl/printEPS. 

6.1.2 Open Inventor 

The Open Inventor drivers for Xt (Unix) and Win32 (Microsoft Windows) also 
provides good interactivity. Figure \T0\ shows a typical screen shot. At present 
this driver cannot render "2D" objects such as non-moving descriptive text. 

It may be worth mentioning that as in OpenGL the view may be saved in 
EPS format via a menu button on the viewer 

6.1.3 Ray Tracer for X 

The Ray Tracer can only render geometry. Figure [TT] shows a typical screen 
shot. The Ray Tracer can also produce JPEG files directly — see Section [6.2.51 

6.2 File-writing drivers 
6.2.1 HepRepFile 

HepRepFile allows the current scene (geometry, event or collections of events) to 
be rendered to an XML file in the HcpRep format. [S] The file can then be read 
into a HepRep browser such as HepRApp.[TO! Because the HepRep file contains 
a full 3D description of the scene, augmented with full physics attribute data 
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Figure 9: A screen shot of an interactive Qt session. 



14 



r\ \^ viewer-1 (OpenlnventorXt) 

RIe Etc Help 




Motion X Motion Y j J Motion ^ 



Figure 10: A screen shot of an Open Inventor viewer. 
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Figure 12: A screen shot of HepRApp browsing a file produced by HepRepFile. 



(attributes of the touchables, trajectories and hits), the HepRApp user can then 
rotate, pan, zoom, change projection styles, pick to view attributes and filter 
graphics based on attributes. Resulting images can be exported a wide variety 
of graphics formats (gif, pdf, etc.). 

Figure 12 shows a screen shot of HepRApp browsing a file produced by 
HepRepFile. 



6.2.2 DAWNFILE 

Similarly, DAWNFILE produces a file suitable for browsing with DAWN.fTT] 
DAWN is capable of sophisticated hidden line and hidden surface removal and 
produces very high quality images in encapsulated PostScript format-see Figure 

m 

One can generate cutaways with DAWNCUT.[T5] A useful spin-off is DAVID, [T3] 
which is a volume overlap detection application. 



6.2.3 VRMLFILE 

Similarly, VRML2FILE produces a file suitable for browsing with a VRML 
browser. Note that VRMLl is still available. 



6.2.4 gMocrenFile 

gMocren[14 is used typically to visualise radiation therapy dose data. Figure 
[M] shows a rendering with a gMocren viewer of a file that has been created with 
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13: A rendering of DAWNFILE output with DAWN. 
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Figure 14: A gMocren rendering of a dose distribution produced with gMocre- 
nFile. 



gMocrenFile after a simulation run. 



6.2.5 Ray Tracer jpeg-writer 

The Ray Tracer can produce a JPEG file, either from its XI 1 version (described 
above, Section 6.1.3 and instantiated with "/vis/open RayTracerX") or from 
this version that needs no graphics library, instatiated within "/vis/ open RayTracer" 



6.2.6 Encapsulated PostScript 

For completeness we re-iterate the possibility, mentioned above, of saving a view 
with any variant of OpenGL or Open Inventor driver to file in EPS format with 
the visualisation command /vis/ogl/printEPS. This can be done even without 
a user interface (see Section[5]) by using the ApplyConmicLndO method of the User 
Interface Manager. The DAWNFILE and HepRepFile drivers can also be used 
in this way to produce files that can be browsed to produce an EPS file. 
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G4ASCIITreeSceneHandler ; : BeginModeling : writing to G4 standard output CG4cout) 

# Set verbosity with "/vis/ASCIITree/verbose <verbosity>" : 

# < 10: - does not print daughters of repeated placements, does not repeat replicas. 

# >= 10: prints all physical volumes. 

# The level of detail is given by verbosity°/olO : 

# for each volume: 



# 


>= 





physical volume name. 




# 


>= 


1 


logical volume name (and names of sensitive detector and readout j 


geometry, if any) 


# 


>= 


2 


solid name and type. 




# 


>= 


3 


volume and density. 




# 


>= 


5 


daughter-subtracted volume and mass. 





# and in the summary at the end of printing; 

# >= 4: daughter-included mass of top physical volume(s) in scene to depth specified. 

# Mote: by default, culling is switched off so all volumes are seen. 

# Note; the mass calculation takes into account daughters, which can be time consuming. If 

# you want the mass of a particular subtree to a particular depth: 

# /vis/open ATree 

# /vis/ASCIITree/verbose 14 

# /vis/scene/create 

# /vis/scene/add/volume <subtree-physical-volume> ! <depth> 

# /vis/sceneHandler/attach 

# /vis/viewer/flush 

# Now printing with verbosity 15 

# Format is; PV:n / LV CSD,RO) / Solid(type) , volume, density, daughter-subtracted volume and mass 

# Abbreviations: PV = Physical Volume, LV = Logical Volume, 

# SD = Sensitive Detector, RO = Read Out Geometry. 

"World":0 / "World" / "World" (G4Box) , 20736 cm3, 1.20479 mg/cm3 (G4_AIR) , 8736 cm3, 10.525 g 

"Envelope" :0 / "Envelope" / "Envelope" (G4Box) , 12000 cm3, 1 g/cm3 (G4_WATER) , 10888.1 cm3, 10.8881 kg 

"Shapel":0 / "Shapel" / "Shapel" (G4Cons) , 175.929 cm3, 1.127 g/cm3 (G4_A-150_TISSUE) , 175.929 cm3, 198.272 g 
"Shape2":0 / "Shape2" / "Shape2" (G4Trd) , 936 cm3, 1.85 g/cm3 (G4_B0KE_C0MPACT_ICRU) , 936 cm3, 1.7316 kg 

Calculating mass(es) . . . 

Overall volume of "World" :0, is 20736 cm3 and the daughter-included mass to unlimited depth is 12.8285 kg 
G4ASCIITreeSceneHandler : : EndModeling 



Figure 15: Typical output of ASCII Tree. 

6.3 BSD Socket drivers 

There are versions of the DAWN and VRML drivers that can communicate with 
their respective browsers though a socket mechanism. The browsers have to be 
launched first and suitable socket numbers chosen. 

6.4 Pseudo-drivers 

We have taken advantage of the way the visualisation system works to write a 
useful pseudo-driver. The visualisation system renders the scene to the "Tree" 
driver and dumps useful information. 

6.4.1 ASCII Tree 

At the moment this is the only tree driver. It dumps the geometry tree to 
standard output and lists the physical volume name and optionally also the 
logical volume name, the solid name, its volume, its density, its mass excluding 
daughters and the total mass of the top physical volume. Figure [15] shows 
typical output. 
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7 Summary 



We have developed a visualisation system that is versatile, powerful and exten- 
sible. It was designed to meet the needs of Geant4 users. It supports sev- 
eral drivers over various graphics libraries, including OpenGL, Open Inventor 
and Geant4's own tracking library (Ray Tracer) and can write files for various 
browsers: DAWN, VRML, HepRApp. It handles the Geant4 geometry hierar- 
chy through a modeling library and can draw particle trajectories from stored 
events in a variety of ways. 
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